home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
MacHack 1996
/
MacHack 1996.toast
/
Hacks
/
Hacks ’90
/
Norstad Hack
/
ReadMe
< prev
Wrap
Text File
|
1990-06-14
|
4KB
|
83 lines
The Disinfectant INIT
A hack by any other name...
John Norstad
Academic Computing and Network Services
Northwestern University
2129 Sheridan Road
Evanston, IL 60208
Internet: jln@acns.nwu.edu
Bitnet: jln@nuacc
CompuServe: 76666,573
AppleLink: A0173
Disinfectant 2.0 includes a new protection INIT designed for novices
and others who find GateKeeper, Vaccine and other "general purpose
suspicious activity monitors" just too damned complicated and obtrusive.
My INIT is tiny (about 4K on disk, about 1K in the system heap),
efficient, simple, and completely unobtrusive. It does not need to
be configured, and in fact has no control panel interface at all. It
does not interfere with programming environments, installers, other
anti-viral tools, or any other kind of software. It only complains if
and when one of the known Mac viruses attacks your system.
The big disadvantage to my INIT, of course, is that it only catches
known viruses.
Despite the fact that the INIT was not written as a hack, it is one
anyway.
When an infected application is run, the viral code in the application
is executed. The INIT uses trap patches to detect the viral code at the
point of its initial attack, before the virus has begun to spread or
cause any other damage. If a virus is detected, the INIT calls the
Notification Manager to alert the user, beeps ten times, and exits to
shell.
Most of the trap patches (six of them in all) detect viral code by
examining locations relative to the return address in the calling
routine. This is similar (although not identical) to Apple "come-from"
patches. As with Apple's come-from patches, if any later patch is a
tail patch, my patch will not work properly. For this reason, I put a
diamond character (◊) in front of the name to force it to sort to the end
of the system folder, and I tell people to try to make certain that my
INIT loads last.
The WDEF virus is a special case, since it infects Finder Desktop files,
not applications. The protection against the WDEF virus is particularly
sneaky. When WDEF attacks, the INIT catches it in one of its trap
patches. It calls the Notification Manager to inform the user and beeps
ten times, as usual. But it doesn't make any sense to exit to shell at
this point, since it's the Finder that's running, not an infected
application.
The INIT locates the pointer to the window record on the stack,
which was passed as a parameter by the Window Manager to the viral window
definition function. This window record contains a handle to the
viral WDEF resource in the windowDefProc field. The INIT replaces this
handle by a handle to the standard system WDEF 0 resource (from ROM or the
system file, as appropriate). It properly checks to see if the machine is
in 32 bit mode, because in 24 bit mode it must store only the bottom 24
bits of the handle, to avoid wiping out the window variant code in top 8
bits of the windowDefProc field. The INIT then unwinds its own stack
frame and the viral WDEF stack frame and jumps to the standard system
WDEF 0.
This hack effectively neutralizes the WDEF virus, at least until the
window is closed and reopened (at which time my INIT catches it again,
alerts the user again, and neutralizes it again). If I didn't do this,
the user would get an infinite sequence of extraordinarily annoying beeps
and alerts.
The user can even continue to use the infected disk, without spreading
the infection or causing any other damage.
Dealing with the MacMag virus is also a special case hack. In this case,
I can't exit to shell, because HyperCard has already hidden the menu bar,
and if I exit to shell, the user still has no menu bar in the Finder.
The hack for this is similar in spirit to the WDEF hack - I mess with
various pointers and locations in memory to neutralize the viral XCMD, and
then I unwind the stack to just the right place and return.